System and method for building a component base architecture

ABSTRACT

A system and method for building a component-based architecture. One or more software components ( 1401 ) are registered with a component-based architecture development environment ( 200 ) in accordance with an interface definition file ( 1406 ). The interface definition file ( 1406 ) identifies one or more methods invocable by the associated component&#39;s encapsulated code. The development environment ( 200 ) enables a user to select the one or more methods for defining component-to-component relationships in a script configured in a hierarchal tree format.

FIELD OF THE INVENTION

This invention generally relates to the field of software developmenttools, and more specifically to development tools usingcomponent-oriented programming constructs.

BACKGROUND OF THE INVENTION

While there are innumerable programming environments at the disposal ofa computer programmer, the general evolution of programming environmentshas been relatively disjointed. Over time, a large variety ofprogramming languages have been developed and employed for differenttasks. For example, as a non-exhaustive list, the C programming languagefamily, including C, C+, C++, and C#, primarily have been used to authordesktop, server, or distributed computer applications, as has BASIC,PASCAL, ADA, TCK/TL, CORBA, and JAVA. For general use in networkapplications, computer programming languages such as the scriptlanguages, including JAVASCRIPT, VBSCRIPT, ASP, and PHP are mostappropriate. For interaction with databases and repositories, SQL is thedefacto programming standard. More recently, XML has emerged as astandard for sharing data between devices and applications.

Initially, each programming language had its respective IntegratedDevelopment Environments (IDEs), with their respective compilers (if itwas a compilable language). However, applications that function indifferent areas of computer technology require a multitude of differenttools and interfaces in order to work together. For example, to tie awebsite to a database, a programmer would use a first web developmenttool to make the graphics and navigation structure of the website and asecond database tool to create the data repository. Unwanted temporaland financial costs can be attributed to the excessive time to learnthese individual tools and become skilled in their operation.

Information within an organization is constantly being organized,stored, transferred and displayed. Within the organization, informationtechnology functions or “zones” needed to handle such informationfrequently overlap and interact. Web services, such as eCommerce,Internet portals, applets and servlets organize information. Databasesystems, including SQL, Oracle, Sybase and other legacy systems storedata. Browsers and applications on the desktop display information.Network applications are used to implement LANs, email systems and othercommunications systems. These information technology functions or zonesneed to interact with one another, however each uses its own separatesoftware.

The software used by these information technology zones all hasdifferent interfaces and standards. It is difficult and expensive for anenterprise to locate and retain the necessary expertise in each of thedifferent technology fields.

As software applications began to require a greater interdependenceamong a variety of computer languages, IDE's were developed that supporta multitude of languages and technology zones. Such IDEs could be usedto write desktop applications, server applications, web pages, databaseapplications, etc. These IDE's comprised a compiler for each compilableprogramming language it supported, and it became easier for computerprogrammers to integrate different computer programming languages.

Yet many of these tools still require a programmer or team ofprogrammers to learn multiple languages. Throughout the evolution ofprogramming, languages were developed to overcome previous shortcomings.Consequently, programming languages today are inherently different fromone another. Not only do languages have different programmatic syntaxes,but also their underlying fundamentals are often dissimilar. The morelanguages that a programmer must learn, the more unwanted financial andtemporal costs can be attributed with creating software programs. Longand complex development cycles are required to develop the software,resulting in greatly increased cost for investing in informationtechnology.

Another problem associated with existing development environments is thelack of code reuse. Advantages to code reuse include faster developmenttimes, lower development costs, and fewer errors in program code. Asignificant step in promoting code reuse was the introduction ofObject-oriented programming (OOP) languages such as C++ and JAVA. OOPallows programming at increasingly higher levels of abstraction—from theobject to the class to the class library and ultimately to the entireapplication framework.

There are three basic techniques that OOP languages use to promote codereuse: inheritance, encapsulation, and polymorphism.

Inheritance is the technique in which one class inherits the structureof data and functionality of a superclass. This allows the programmer tocreate new classes by using the member data and functions from anexisting class and adding or modifying existing functionality, therebypromoting code reuse.

Encapsulation is the technique of separating the internal operations anddata structure of an object from the interface that is exposed to therest of the program. As software becomes complex, encapsulation isimportant in maintaining the software as well as extending itsfunctionality.

Polymorphism is the technique of having objects behave differently basedon the parameters passed to them. Polymorphism allows a programmer touse objects as specialized instances of their more generic types.

Progress in OOP has also left it with certain drawbacks. Objects in OOPare confined to a single program, and its reuse is not supported outsideof the compiler that created the object. There is no way of accessingthese objects for multiple programs. To overcome this drawback,distributed objects were developed.

Unlike traditional objects, distributed objects, also known as softwarecomponents, are pieces of software that can be accessed by differentnetworks, operating systems, and tool palettes. A component is not boundto a particular program, computer language, or implementation. ACTIVEXby MICROSOFT, and JAVABEANS by SUN MICROSYSTEMS are the competingcomponent standards for the desktop. These components are toolable,meaning they can be imported within a standard IDE where it can bereused and also customized. COM+ by MICROSOFT, ENTERPRISE JAVABEANS(EJBs) by SUN MICROSYSTEMS, and CORBA BEANS by OBJECT MANAGEMENT GROUPare the competing component standards for the server.

Some visual programming IDE's such as MICROSOFT'S VISUAL STUDIO, IBM'SVISUAL AGE, or SUN MICROSYSTEMS' ONE STUDIO support toolable components,particularly ACTIVEX and JAVABEANS. Using “drag & drop” methods and someautomatic code generation, components can be incorporated into customprograms. However, these environments still require extensiveprogramming, and all require a knowledge of programming to operate.Unwanted temporal and financial costs persist even with the benefits ofvisual programming IDEs.

Some attempts have been made to create a complete Component-OrientedProgramming (COP) environment. However, these COP environments have manydrawbacks.

U.S. Pat. No. 6,044,218, Faustini, discloses a system for a live appletor application development visual programming environment thatincorporates components for socialization therein. However, there areseveral drawbacks of this system.

Firstly, the system limits a programmer to designing only applets orapplication programs because deployment is dependent on the developmentenvironment. Other types of programs, such as servlets, portlets, HTMLor XML file creation scripts, UNIX or PERL scripts, or other softwarecomponents cannot be designed with the system of the '218 patent.

Secondly, the system of the '218 patent does not use an intuitive andefficient user interface. For example, looking at FIG. 16 of the '218disclosure, a very simple applet is created using components, yet it isvery difficult to decipher the operations of each component. The “wire”connectors between components are already difficult to trace.Furthermore, if a component has several dozen or more “connectors”, itbecomes very difficult to display these connectors in conjunction withthe component icon.

Thirdly, the development environment is inefficient and overly complex.The system of the '218 patent has a “what-you-see-is-what-you-get”(WYSIWYG) GUI builder which displays the physical view of the GUI. Whilecomponents are displayed in both the physical view window and thelogical view window, there is no relationship between each that isdisplayed to the user. This separation of the physical and logical viewsis a drawback.

U.S. Patent Application Publication No. 2002/0053070 A1 discloses amethod of developing an application that is capable of flexibly copingwith a variation in system environment, such as a system platform, fordevelopment of a component-based application. However, this method isoverly complex since it includes both a physical component descriptionand a logical component description.

U.S. Patent Application Publication No. 2002/0104073 A1 discloses a COPlanguage which enables the definition of a multi-component structure ofa system. Still, there are several drawbacks with such a definition.

Firstly, the COP language is limited to describing the JAVA BEANarchitecture. That is, only components compatible with the JAVA BEANcomponent specification may be described using this COP-definedlanguage. Such a limitation disregards a significant design feature ofcomponent programming, which is the use of components withoutconsideration for its encapsulated code. Components scalable to theenterprise which support multiple sessions, such as ENTERPRISE JAVABEANS(EJB), are not supported by this COP language.

Secondly, the COP language does not support event-binding betweencomponents of multiple languages. The COP language describes the exactinterconnections between a JAVABEAN and its methods to call otherJAVABEANS. The COP language does not sufficiently abstract theinterconnections made by the underlying components. Consequently, itbecomes very difficult or virtually impossible for a developmentenvironment to identify components having compatible interfaces, whichis further made problematic when working with components programmed inmultiple languages. Such a drawback would place additional unwanted andcostly demands on the user or programmer to have prerequisite knowledgeof the components.

Thirdly, because an uncompilable markup language defines the COPlanguage, a program cannot flexibly be deployed to a native language orenvironment, or multiple languages and multiple environments, whichprovides obvious advantages. That is, the COP language does not provideany type of compilation or deployment instructions.

From the foregoing, it should be apparent there is a deficiency in theprior art and a need for a simple and efficient way to share softwarecomponents between users.

SUMMARY OF THE INVENTION

The present invention overcomes the deficiencies of the prior art byproviding a component-based architecture development environment. Theinvention provides the ability to develop entire software programswithin a single, seamless programming environment using a set ofcomponents that encapsulate the functionality of databases, web servers,application servers, GUI development tools, parsing tools, math tools,graphics tools, and any variety of other functionality. Further, theinvention may be used to rapid prototype software programs forfeasibility analysis.

In one embodiment of the invention, a refined 3D graphical interfaceallows users to build and test scripts on the fly without keying inlines of program code.

The development environment provides for operatively connecting aplurality of components for building a component-based script. Thescript can be deployed to a component-based architecture.

The development environment makes use of an extended componentarchitecture. It builds upon industry standards for component creationallowing integration of customized or third party components. Thereforenew components can be added or existing components updated to increasethe software's functionality.

One feature of the present invention is the novelty of the componentframework. A component framework comprises a component wrapper toabstract the interconnections made by the underlying component binaries.This abstraction is advantageously exploited by the developmentenvironment to provide more direct control over component interactionsand relationships. In this manner, the development environment canemploy such novel features as automatically identifying componentshaving compatible interfaces, which relieves the user of the developmentenvironment from the burden of having previous knowledge of programmingand knowledge of the components. The abstraction allows a user tomanipulate component interactions even while a script is running. Thecomponent wrappers are still further abstracted to an interfacedescription file which describes the interface of the component wrapper.

The present invention can be used to develop component-based scripts andarchitectures in any of the information technology zones, greatlyreducing the cost and amount of time needed to develop a program. Still,it would be advantageous to be able to share logic components betweendifferent development zones to quickly and efficiently developarchitectures for multiple environments.

In one embodiment of the present invention, a “logic hub” or “peernetwork” is provided for integrating information technology zonesthrough the sharing of software components. Components can be exchangedover a network, such as a local network or global network like theInternet. The interface description file provides a description standardfor sharing components over the network.

In still yet another embodiment, a peer group can collaboratively workon a script from one or more workstations networked to a central server.

BRIEF DESCRIPTION OF THE DRAWINGS

The following detailed description, given by way of example and notintended to limit the present invention thereto, will best beappreciated in conjunction with the accompanying drawings, wherein likereference numerals denote like elements and parts, in which:

FIG. 1 shows a block diagram of a computer system in accordance with oneembodiment of the invention;

FIG. 2 shows a block diagram of a component-based architecturedevelopment environment in accordance with one embodiment of theinvention;

FIG. 3 shows an example of a display interface in accordance with oneembodiment of the invention;

FIG. 4 shows an example of the interacts window of the display interfacein accordance with one embodiment of the invention;

FIG. 5 shows an example of a display interface with an “Environment”node selected in accordance with one embodiment of the invention;

FIG. 6 shows an example of a display interface with a “Program Type”method selected in accordance with one embodiment of the invention;

FIG. 7 shows an example of a display interface with an “Application”node selected in accordance with one embodiment of the invention;

FIG. 8 shows an example of a display interface with an “On Start” methodselected in accordance with one embodiment of the invention;

FIG. 9 shows an example of a display interface with a “Window” nodeselected in accordance with one embodiment of the invention;

FIG. 10 shows an example of a display interface showing a componentscript in accordance with one embodiment of the invention;

FIG. 11A-B shows the script of FIG. 10 running in the developmentenvironment in accordance with one embodiment of the invention;

FIG. 12A-B shows an example of a display interface showing hide andreveal states of a component script in accordance with one embodiment ofthe invention;

FIG. 13A-C shows an example of a display interface showing expanded,collapsed, and intermediary states of a component script in accordancewith one embodiment of the invention;

FIG. 14 shows a block diagram of a component framework in accordancewith one embodiment of the invention;

FIG. 15 shows an example of a component description file in accordancewith one embodiment of the invention;

FIG. 16 shows an example of a script file in accordance with oneembodiment of the invention;

FIG. 17 shows a flow chart for an initialization process in accordancewith one embodiment of the invention;

FIG. 18 shows a flow chart for a script loading process in accordancewith one embodiment of the invention;

FIG. 19 shows a flow chart for a run process for running a script inaccordance with one embodiment of the invention; and,

FIG. 20 shows a flow chart for a deployment process in accordance withone embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description of one embodiment of theinvention, reference is made to the accompanying drawings, which form apart hereof, and in which is shown by way of illustration of a specificembodiment in which the invention may be practiced. This embodiment isdescribed in sufficient detail to enable one skilled in the art topractice the invention. It will be understood that other embodiments maybe utilized and that structural changes may be made without departingfrom the spirit and scope of the present invention. The followingdetailed description is, therefore, not to be taken in a limiting sense.

The present invention may be implemented using hardware, software or acombination thereof and may be implemented in one or more computersystems or other processing systems. In fact, in one embodiment, theinvention is directed toward one or more computer systems capable ofcarrying out the functionality described herein. An example of acomputer system 100 is shown in FIG. 1. Computer system 100 includes oneor more processors, such as processor 102. Processor 102 is connected toa communication infrastructure 104 (e.g., a communications bus,cross-over bar, or network). Various software embodiments are describedin terms of this exemplary computer system. After reading thisdescription, it will become apparent to a person skilled in the relevantart(s) how to implement the invention using other computer systemsand/or computer architectures.

Computer system 100 can include a display interface 106 that forwardsgraphics, text, and other data from communication infrastructure 104 (orfrom a frame buffer not shown) for display on a display unit 108.

Computer system 100 also includes a main memory 110, preferably a randomaccess memory (RAM), and may also include a secondary memory 112.Secondary memory 112 may include, for example, a hard disk drive 114and/or a removable storage drive 116, representing a floppy disk drive,a magnetic tape drive, an optical disk drive, etc. Removable storagedrive 116 reads from and/or writes to a removable storage unit 118 in awell-known manner. Removable storage unit 118, represents a floppy disk,magnetic tape, optical disk, etc. which is read by and written to byremovable storage drive 116. As will be appreciated, the removablestorage unit 118 includes a computer usable storage medium having storedtherein computer software and/or data.

In some embodiments, secondary memory 112 may include other similarmeans for allowing computer programs or other instructions to be loadedinto computer system 100. Such means may include, for example, aremovable storage unit 120 and an interface 122. Examples of such mayinclude a program cartridge and cartridge interface (such as that foundin video game devices), a removable memory chip (such as an EPROM, orPROM) and associated socket, and other removable storage units 120 andinterfaces 122 which allow software and data to be transferred fromremovable storage unit 120 to computer system 100.

Computer system 100 may also include a communication interface 124.Communications interface 124 allows software and data to be transferredbetween computer system 100 and external devices. Examples ofcommunications interface 124 may include a modem, a network interface(such as an Ethernet card), a communications port, a PCMCIA slot andcard, etc. Software and data transferred via communications interface124 are in the form of signals, which may be electronic,electromagnetic, optical or other signals capable of being received bycommunications interface 124. These signals are provided tocommunications interface 124 via a communications path (i.e., channel)126. Channel 126 carries the signals and may be implemented using wireor cable, fiber optics, a phone line, a cellular phone link, an RF linkor other communications channels.

In this document, the terms “computer program medium” and “computerusable medium” are used to generally refer to media such as removablestorage drive 116, a hard disk installed in hard disk drive 114, and orsignals. These computer program products are means for providingsoftware to computer system 100. The invention is directed to suchcomputer program products.

Computer programs (also called computer control logic) are stored inmain memory 110 and/or secondary memory 112. Computer programs may alsobe received via communications interface 124. Such computer programs,when executed, enable computer system environment 100 to perform thefeatures of the present invention as discussed herein. In particular,the computer programs, when executed, enable processor 102 to performthe features of the present invention. Accordingly, such computerprograms represent controllers of computer system 100.

In an embodiment where the invention is implemented using software, thesoftware may be stored in a computer program product and loaded intocomputer system 100 using removable storage drive 116, hard disk drive114, or communications interface 124. The control logic (software), whenexecuted by processor 102, causes processor 102 to perform the functionsof the invention as described herein.

In yet another embodiment, the invention is implemented using acombination of both hardware and software.

In accordance with one embodiment of the present invention, acomponent-based architecture development environment 200 comprises agraphical user interface (GUI) 202, a component manager 204, an instancemanager 206, and a deployment manager 208.

GUI 202 provides a graphical display of a development environment 200 toa user for manipulating interactions between components. The structureand operation of GUI 202 is disclosed in further detail in the “GUI 202”section of this disclosure.

Component manager 204 manages the component registration process forregistering components for use in creating software scripts. In thisdocument, the terms “script” and “component tree” are usedinterchangeably. The structure and operation of component manager 204 isdisclosed in further detail in the “Component Manager 204” section ofthis disclosure.

Instance manager 206 manages component interactions in the currentscript. The structure and operation of instance manager 206 is disclosedin further detail in the “Instance Manager 206” section of thisdisclosure.

Deployment manager 208 manages the build and deploy process of thecurrent script to a component-based architecture. The structure andoperation of deployment manager 208 is disclosed in further detail inthe “Deployment Manager 208” section of this disclosure.

1. GUI 202

FIG. 2 shows GUI 202 in accordance with one embodiment of the presentinvention. GUI 202 is a refined 3D graphical interface that allows usersto build and test scripts on the fly without keying in lines of code.GUI 202 comprises a canvas 302, an interacts area or window 304, adrop-down menu toolbar 306, and a fast access toolbar 308.

Canvas 302 provides screen space for displaying a script's componenttree. Canvas 302 provides an area for the user to manipulate and definecomponent interactions, thereby building the component tree of a script.A component tree on canvas 302 consists of one or more softwarecomponents. Unlike much of the prior art which uses interfaces that“wire” components together, or interfaces providing a physical view ofthe graphical windows and components of the application being built, thepresent invention displays a hierarchal tree format representing acomponent script showing not just which components interact but also howthey interact. The hierarchal tree comprises multiple hierarchal levels,each level comprising one or more components. An interaction, orconnection, between one component of one hierarchal level and onecomponent of another hierarchal level is shown as a function of a methodto be invoked at runtime by the script.

The highest hierarchal level of a component tree consists of a single,root component. In one embodiment of the invention, its root componentwill be an Environment component regardless of a script's purpose. Asshown in the example of FIG. 3, canvas 302 has an Environment componentin the component tree.

Interacts window 304 is a modeless window which displays methodselections available to define the interactions between components ofdifferent hierarchal levels. To manipulate the behavior or extend thelogic of a component tree, a user selects an existing component from thetree on canvas 302. Interacts window 304 only displays the methods thatmay be invoked by the selected component. A user-actuated selection ofone of these methods expands the selection to reveal a list ofregistered components that may be passed as the method's parameter(often referred to as the method's “argument”). A user-actuatedselection of the component will set it to the current script. Theselected method defines the interaction, which is visually displayed tothe user, between the existing component and this new component.

Many components can only be configured in specific interactions asgoverned by their interface definition. For example, because a scrollbar may appear within a window, a Window component would have a methodthat takes a ScrollBar component as its parameter. In contrast, a windowwould never appear inside a scroll bar, so the ScrollBar component wouldnever have a method that takes a Window component. Developmentenvironment 200 implements these configuration rules for the user inaccordance with a component framework disclosed herein. Developmentenvironment 200 automatically identifies components having compatibleinterfaces, so that a script is as fault tolerant as the encapsulatedfunctionality of the components themselves.

Drop-down menu toolbar 306 comprises a series of drop-down menus formanaging development environment 200. These menus include importingscripts, building and deploying scripts, running scripts, accessing helpfiles and examples, etc.

Fast access toolbar 308 includes icons for quick access to some of themore frequented options available from drop down menu 306.

Referring now to FIG. 4, there are generally three types of methodselections that a user may find in interacts window 304: Componentmethod selections 402, Property method selections 404, and Commandmethod selections 406.

Component method selections 402 comprise component methods that set anew component into the script. A new component is instantiated as achild component of a parent, wherein child components extend the logiccapability of their parent component. Child components react differentlydepending on their parent component. For example, a WebPage componentmay be added to an existing Servlet component.

Property method selections 404 include property methods that set a valueto a property, which is an atomic, immutable element that defines acomponent. For example, a HTMLPage component may have a Title property,or a BackgroundColor property, each set by a property method. Or, aproperty may also denote action in its parent component by notifying itthat an event needs to be handled. For example, a HTMLPage component mayhave a DoFocus property that is triggered by another component.Hereinafter, this type of property will be referred to as a “trigger”.According to one embodiment, names of triggers generally begin with a“Do” in their title.

Property methods set the property by receiving data from one of twospecial components: a link component or a link constant component.

A link defines a property whose value is asserted by another componentof the component tree. That is, the property of a component is setdynamically during execution of a script. Links can be either of theinput or output type, and a link of one type is connected to a link ofthe other type. For example, an HTMLPage component's Title property maybe set by an input link connected to an output link of a Databasecomponent. Triggers always have a link component set as their childcomponent.

A link constant defines a property statically, the value being set bythe user. A link constant stores a static value for the parentcomponent. For example, a user may set an HTMLPage component's Titleproperty to “My Home Page”. This value remains static during executionof the script.

Command method selections 406 include command methods that denote actionwithin the component structure itself. A command method's name generallybegins with “On”, for example, OnConnect or OnStart. A command methodgenerates action by its parent component. For example, a Databasecomponent may invoke an OnConnect command method that, once the scriptconnects to a database via a Database component, sets up an XML Producercomponent to log data transactions to an XML file. A command method canalso trigger action in another component in cooperation with the linkcomponents. For example, a HTMLPage component may have an OnRefreshcommand that, when a user refreshes the page, triggers an event in aDatabase component.

The true flexibility and simplicity of the present invention may best bedisclosed through an example. The following example is for explanatorypurposes only, and is not intended to limit the invention in scope, norshould it be taken in a limiting sense.

To build a script from scratch, a user selects the root component toshow the methods available thereto as illustrated by FIG. 5. Interactswindow 304 shows one method displayed as “Program Type” which, wheninvoked by the Environment component, sets a new component to thescript. Represented by the hierarchal tree, this new component falls tothe next hierarchal level. The ProgramType method is of the componentmethod-type.

As shown in FIG. 6, clicking on the ProgramType method reveals threecomponents that the ProgramType method may receive as its parameter: anApplet component, an Application component, or Clipboard component.While the present embodiment shows three compatible components that areregistered, it is important to note that a novel feature of the presentinvention is the ability to register and incorporate new components toextend the flexibility of development environment 200. There is no limitto the number of components that may be attached to the root component.Because the tree starts not from the application level or applet level,but at an environment level, it permits multiple applications or appletsin the same hierarchal tree. It is possible for multiple applications orapplets under the same root component to work synergistically. Forexample, one application could provide server services while anothercould provide client services. By running the script, the server andclient services could interact and share data therebetween.

Selecting the Application component sets it to the component script. AsFIG. 7 shows, canvas 302 is updated to reflect this action. Thecomponent script has two hierarchal levels, wherein the interactionbetween the Environment component and the Application component isdefined by the ProgramType method. Selecting the Application componentof the component tree reveals two methods in interacts window 304: aDeployName property method and an OnStart command method.

FIG. 8 shows interacts window 304 after a user has selected the OnStartmethod. The OnStart method receives a component that is instantiated atthe initial execution of its parent component.

FIG. 9 shows an updated canvas 302 after a user has selected to pass theOnStart method a parameter of the Window component type. It should beappreciated that although not illustrated by example, multiple OnStartmethods can be selected to be invoked by the Application component. Atruntime, each invoked method receives the respective component so that auser can choose to create multiple windows at boot of the compiledscript, or a variety of differing components, such as a Webservercomponent and a Database component. This is true of any combination ofmethods and their arguments as can be seen in FIG. 10.

FIG. 10 shows canvas 302 after the user has set several components tobuild the component tree. Method 1002 will be invoked three times by theGridLayout component during runtime execution, which is indicated usingconnect bars 1004 for GUI 202 refinement and simplicity. Each methodinvocation receives a different component as its argument, demonstratingthe versatility and modularity of the present invention'scomponent-based architecture development environment 200.

Also, FIG. 10 shows GUI 200 displaying a constant link component 1006and a link component 1008, 1010 in the component tree. Constant linkcomponent 1006 has a static value set thereto, which is displayed to theuser. In this example, constant link 1006 has a value of “1”. Linkcomponent 1008 is dynamically set by connecting to link component 1010with connect bar 1012. Small arrows on each link component 1008, 1010indicate the direction of data flow. In this example, a running scriptwill perform the On Action method of the Button component, whichtriggers the Do Send Text trigger property of the Text Field component.

As FIG. 10 illustrates, the connect bars of other link components arehidden from view until a user selects one of the link components. Uponselection, the currently displayed connect bar will be hidden, and theconnect bar of the selected link component will be displayed to show anyinteraction. Without this hide and reveal feature, canvas 302 may becomeovercrowded, making it difficult for a user to trace componentinteractions. Also of note is that connect bars 1004 group multiplecomponents to a single method 1004 for display simplicity.

FIG. 11A-B shows the running script of FIG. 10. The script is being runwithin development environment 200, and has not been separatelydeployed. In this running script, a user can type text into the textfield of FIG. 11A. At the press of the button at the bottom of thewindow, the label is updated with text from the text field as shown inFIG. 11B.

In addition to those features already described, there are several otherfeatures promoting the efficient use of space on canvas 302. Thesefeatures are especially useful when working with complex scripts havinglarge component trees.

GUI 200 includes a feature for hiding and revealing select portions ofthe component tree. Components below a user-selected component in thehierarchal tree may be toggled between a hidden state and a revealedstate.

FIG. 12A shows a large component tree in which screen real estate isscarce. Only a portion of the component tree is visible to the user atany one time. While standard scroll bars at the bottom and right side ofthe window make navigation possible, it remains difficult to fullyappreciate the complexities and intricacies when manipulating componentsof the tree. Selecting any component of the tree, such as selectedWindow component 1202, reveals a toggle button 1204. Toggle button 1204points in the upward direction, indicating that Window component 1202 isin the revealed state in which components below Window component 1202are displayed.

Selecting toggle button 1204 switches Window component 1202 to thehidden state as shown in FIG. 12B. All components below Window component1202 are hidden, making navigation and study of the component tree moremanageable. Toggle button 1204 now points downward, signifying Windowcomponent 1202 is in the hidden state.

Second, GUI 200 includes a feature for expanding and collapsing a tree.A user can perform a “click-and-hold” action with a mouse pointer oncanvas 302 and drag left or right to expand or collapse the componenttree in real time, enabling an unlimited number of intermediatepositions in which a user may situate the tree.

FIG. 13A shows a tree in a fully expanded state. As the tree becomesmore complex, it may be beneficial to the user to collapse the tree sothat more comes into view on canvas 302.

FIG. 13B shows the component tree in a fully collapsed state. However,if the user prefers, any number of intermediate positions between afully expanded state and fully collapsed state can be achieved with thepresent invention. This feature has the advantage of customizing thesize of the tree to the size of canvas 302. FIG. 13 c shows just one ofthese intermediate positions. The component tree remains fullyinteractive at any of these positions.

GUI 202 includes a “Run” button to run a script on canvas 302.Development environment 200 has the capacity to allow components of arunning script to be modified on-the-fly without stopping the scriptexecution. This enhances a user's ability to efficiently debug thescript, without having to spend time stopping, recompiling, andre-running the script. Components can be added, deleted, or moved whilea script runs. If the script is running and the component tree ismodified, development environment 200 reacts to the changes byincorporating them into the currently running script. The script can bestopped at any time by clicking on a “Stop” button on toolbar 308 or a“Stop” selection from drop-down menu 306.

At the direction of a user, a script on canvas 302 can be built anddeployed using a “one-click” deployment process. To use, the user simplyselects the component to be deployed in the component tree, and thenone-clicks a “Build and Deploy” button on toolbar 308 or a “Build andDeploy” selection from drop-down menu 306. The deployment processtraverses each component of the component tree, wherein each componentis responsible for compiling its own source code (if it is a compilablelanguage). Each component is responsible for incorporating allsupporting files.

Each component has a build method encapsulated therein which generatescompiled code based on the parameters reflected in the component tree.Servlets, EJBs, portlets to a webserver, HTML files, or XML files may bebuilt and deployed in this manner, as well as any other type ofsoftware. UNIX shell and PERL scripts could be generated on the flyusing this technique. The deployment process will be further appreciatedupon full disclosure of the present invention.

GUI 202 provides the ability to create a function from a portion of ascript. This feature makes it simple to reuse commonly arrangedcomponents in multiple scripts without having to rebuild the functionalarrangement each time. A function is a group of components that can beloaded into other scripts collectively with their interconnectionspreserved. The process for creating a function includes two steps: anexternalize step and a function creation step.

GUI 202 provides an “Externalize” button or selection for execution forthe externalize step and a “Create Function” button or selection forexecution of the function creation step. A component is selected by theuser to be externalized before the function is created. Externalizingprovides an exception for the collective grouping of the selectedcomponent's parent's method. For example, if a user wants to create afunction which included an HTMLPage component having a set color andheader, but wanted to allow someone to add components under it, the userwould create an HTMLPage component, set its color and header propertycomponents, and add a child component such as a Table component using aAddComponent method. The user would then externalize the Table componentby selecting it in the tree and selecting the “Externalize” button orselection. A user may then execute the function creation step byselecting the HTMLPage component and selecting the “Create Function”button or selection. The HTMLPage component and all components below inthe hierarchal level are collectively saved as a function with theexception of the externalized Table component. The user has the optionto name the function before it is saved. Once the function is createdand saved, it will appear in Interacts window 304 identified by itsuser-defined name and in association with methods taking an HTMLPagecomponent parameter. If a user adds the user-defined function to ascript, the tree on canvas 302 is updated and Interacts window 304 showsonly the externalized methods as method selections, which in the currentexample is the AddComponent method. The color and title properties arestatically set as before and cannot be changed.

2. Component Manager 204

One familiar in the art will fully appreciate the component registrationprocess managed by component manager 204 upon disclosure of the noveltyof the component framework used in accordance with one embodiment of thepresent invention.

FIG. 14 shows a component framework 1400 supported by developmentenvironment 200 for building software scripts. Framework 1400 providesfor the separation of a component's implementation and correspondinginterface definition. The flexibility and interactivity of thecomponent-sharing feature of the present invention is then possible.Framework 1400 contains the necessary files for importing componentsinto development environment 200 for building and manipulating functionsor scripts. Component framework 1400 comprises one or more components1401 a-1401 n, each having a three-tier architecture comprising acomponent binary 1402, a component wrapper 1404, and an interfacedefinition file 1406.

Component binary 1402 comprises the implementation portion of framework1400. Component binary 1402 is a compiled object class that implementsthe methods, properties, and events encapsulated therein. In accordancewith industry software component standards, component binary 1402 iscapable of encapsulating any functionality written in any programminglanguage on any system framework so as to preferably provide completeportability of framework 1400 to any platform. The extent offunctionality encapsulated by component binary 1402 is not limited, sothat any type of script may be created by a combination of components.There are no limits on complexity or simplicity. For example, componentbinary 1402 may encapsulate a webserver, applet, webpage, scroll bar,hyperlink, graphic, etc.

Component binary 1402 abstracts to component wrapper 1404 whichcomprises the interface portion of component 1401. Component wrapper1404 permits component binary 1402 to interface with developmentenvironment 200. This abstraction allows any component binary 1402 to beregistered in development environment 200 without having to be rewrittenor altered at the component level. Development environment 200advantageously exploits the interface abstraction to wrapper 1404 toprovide more direct control over interactions between component binaries1402. Under component framework 1400, any interactions in a runningscript between a plurality of component binaries 1402 pass data to theirrespective wrappers 1404, where the data exchange can be directlymanaged by development environment 200.

If the particular component 1401 is deployable, component wrapper 1404will have an individual build method for building and deployingcomponent binary 1402 in a script. Therefore, each component 1401 canhave different build methods for appropriately deploying correspondingcomponent binary 1402 in a deployment process.

The interface of component binary 1402 abstracted to component wrapper1404 is still further abstracted to interface description file 1406.

Each component wrapper 1404 has a corresponding interface descriptionfile 1406 comprising the interface definition portion of component 1401.Description file 1406 is of a proprietary file type describing theinterface of component wrapper 1404 with a description schema in astructured markup language. In the present embodiment, a description ineXtensible Markup Language (XML) is encoded in description file 1406that can be read and written by development environment 200. Descriptionfile 1406 describes the interface of the associated wrapper 1404. Bydefining the interface in a structured markup language, developmentenvironment 200 (or other tools) do not have to be pre-programmed to befamiliar with a particular component wrapper 1404. Instead, theinterface is loaded from interface description file 1406 to registercomponent wrapper 1404 and corresponding component binary 1402 withdevelopment environment 200. In this manner, component 1401 becomesregistered.

Different technology zones can share logic seamlessly, for example, overa network. The markup language of interface description file 1406facilitates the exchange of components 1401 over a network. A user canview meta-information about component 1401 from description file 1406before using in a script. The structured markup language encoded indescription file 1406 allows for easy conversion to tools other thandevelopment environment 200.

Description file 1406 includes three main sections each shown in FIG.15: a meta section 1510, an interface section 1520, and a component-treesection 1530.

Meta section 1510 contains basic meta-information about interfacedescription file 1404. Meta section 1510 describes which version ofdevelopment environment 200 generated description file 1406 (includingversion number and date), the author, and optionally, the last modifieduser. Meta section 1510 plays an important role if component is beingshared over a network with other users. In the present embodiment, metasection 1500 is denoted by <meta> and </meta> tags.

Interface section 1520 provides the interface definition for theassociated component wrapper 1404 by identifying its methods. In thepresent embodiment, Interface section 1520 is denoted by <interface> and</interface> tags.

Interface section 1520 includes at least one display-name sectionidentifying the name of the associated component 1401, and at least onedescription section providing a brief summary of the associatedcomponent's capabilities. These sections are used for display on GUI 202of development environment 200, so that a user may identify and choosecomponents for creating a script, or for self-generating “Help” files.The example of FIG. 15 shows a description file that is describing theinterface for a component wrapper 1404 of an HTMLPage component 1401.Interface section 1520 may include multiple display-name sections andmultiple description sections for more than one language.

Interface section 1520 further includes a types section comprising oneor more type sections, each type section identifying a class of whichthe present component wrapper is an inheriting subclass. Methods thatmay be passed those object types identified in the types section of thisor other components will accept this component 1401.

Following the types section, interface section 1520 consists of one ormore method sections. Each method section identifies an attachment pointinto component wrapper 1404 that another component wrapper 1404 canattach to. Therefore, component wrappers interconnect the underlyingcomponent binaries 1402 in development environment 200. The methodsection identifies the name of a method encapsulated in componentwrapper 1404 that interfaces with development environment 200. Eachmethod section further comprises one or more parameter sections,display-name sections, and description sections.

The parameter section identifies the object type passed to the method atinvocation. This parameter section, in conjunction with anotherwrapper's interface type sections, dictates which interactions can existbetween components 1401. Only wrappers 1404 with the identical class orsubclass encoded in the interface types section are compatible with themethod. In the example of FIG. 15, one method encoded is a setTitlemethod which takes an object of the LinkReceive type. This indicatesthat component wrapper 1404 implements a method named “setTitle” whichtakes component wrappers 1404 with a LinkReceive interface type. Thus,component binaries 1402 having compatible component wrappers 1404 can beinterconnected.

Information encoded in display-name and description sections arepresented on GUI 202 of development environment 200 so that a user mayidentify and choose methods of the present component for building ascript, or for self-generating “Help” files.

Component-tree section 1530 comprises a class-name section identifyingcorresponding component wrapper 1404. In the present embodiment,component-tree section 1530 is denoted by <component-tree> and</component-tree> tags.

The example of FIG. 15 shows description file 1406 of thecomponent-type, which is included in component 1401 of componentframework 1400. There are two additional variations of this file: ascript-type for defining a component script and a function-type fordefining a function.

A script-type file provides the information necessary to reconstruct auser-built script that may have been written during a previous authoringsession. A script file includes data necessary for assembling componentsof the user-script in the proper tree configuration within developmentenvironment 200. While a script-type file has an identical meta sectionformat as interface description file 1406, variations exist with theformat of the interface and component-tree sections. An example scriptdefinition file 1600 is shown in FIG. 16.

The interface section of a script-type file identifies the rootcomponent of the script and the root component's invocable method(s).Interface section 1620 identifies the root component as an Environmentcomponent with an addEnvironmentChild method.

The component-tree section of the script file holds data forreconstructing the tree hierarchy of a saved script. As shown in theexample of FIG. 16, the component-tree section of script-type file 1600begins with a root Environment component. Spawning from the Environmentcomponent is an ApplicationEnvironment component. TheApplicationEnvironment component is added to the tree in accordance withthe addEnvironmentChild method of its parent Environment component. Iflinks or constants were set in the script, these too are preserved inscript file 1600.

A function-type description file is similar to a script-type descriptionfile with some exceptions. First, any externalized methods are set asparameters. Second, the component-tree section does not necessarilybegin with a root Environment component. Instead, it begins with thefirst component in the function script.

Component manager 204 is an integral constituent of an initializationprocess 1700 executed by development environment 200 and shown in FIG.17. Preferably, process 1700 is performed at each boot of developmentenvironment 200.

Process 1700 beings at block 1702 and proceeds to control block 1704 atwhich stored or default user preferences are loaded to developmentenvironment 200. Preferences include default and custom graphical windowsettings including size and position, file paths to directories forstoring and retrieving saved scripts, a file path to the compiler, alicense server IP address if being hosted by a server (for example, byJAVA WEBSTART), etc. Because development environment 200 reads thepreferences file on boot, the user is relieved from the burden ofinputting this information each time development environment 200 isused, as well as allowing for a custom graphical look and feel to whichthe user is accustom.

Once user preferences are loaded and set, components 1401 available todevelopment environment 200 for building and deploying scripts areregistered with development environment 200 at control block 1706.Component registration improves the speed and processing efficiency ofdevelopment environment 200.

Component registration begins with the instantiation of componentmanager 204, which parses a component registration file that lists theexisting components 1401 available to development environment 200. Inone embodiment, this component registration file is initially generatedby a search of the local system for components 1401. It should beappreciated that in other embodiments, the component registration filemay be alternatively generated such as, for example, searching a networkfor existing components.

Once parsed, component manager 204 creates a component data object foreach component 1401 identified in the registration file. Eachcomponent's corresponding interface definition file 1406 is parsed andstored in volatile memory according to the component object datastructure. The component object data structure maintains the interfacetypes, display names and descriptions, as well as an object holding theinvocable methods of component wrapper 1404.

Using this information, component manager 204 sets two hash tables tovolatile memory.

The first hash table has its key holding the names of component wrappers1404 mapped to their respective component data objects. This first hashtable is accessed when running a script and during the one-clickdeployment process of a script.

The second hash table has its key holding the names of componentwrappers 1404 mapped to an array of component data objects stipulated inthe interface types sections of corresponding interface definition files1406. This second hash table is used to quickly and efficiently identifycomponent wrappers 1404 that may be passed as an argument to methodstalking the interface types identified in the key. GUI 202 displays theidentified components to the user in interacts window 304 when a userselects a method for extending the logic of the component tree. Forexample, the key of the hash table may hold an EnvironmentChildcomponent whose implementation is a public interface. If anApplicationEnvironment component and an AppletEnvironment component eachimplement the EnvironmentChild interface component, then theEnvironmentChild component will be listed in the interface types sectionof each ApplicationEnvironment and AppletEnvironment interfacedefinition file 1406. Therefore, any method receiving anEnvironmentChild component-type can receive its respectiveimplementations, including ApplicationEnvironment and AppletEnvironment,which are in an array mapped to the EnvironmentChild key of the hashtable.

Component registration 1706 is complete once these relationships aremapped in the hash tables.

At block 1708, instance manager 206 is instantiated and initialized.Instance manager 206 handles management duties for a script, includingmanaging component interactions in the script. Instance manager 206 isaptly named because it manages the “instances” of components in ascript. On instantiation, instance manager 206 creates an array ofinstance data objects initially set to hold one instance of the rootEnvironment component. As previously noted, scripts begin with theEnvironment component. The instance data type is disclosed in furtherdetail in the next section of this disclosure.

Upon completion at block 1710 of initialization process 1700,development environment 200 displays GUI 202 to the user as shown inFIG. 3.

3. Instance Manager 206

A tree's data structure organizes the components of a script andinteractions therebetween as defined by their methods. The hierarchaltree's data structure is primarily comprised of two types of datasub-structures, each managed by instance manager 206: an instance datatype and a logic node data type.

The instance data type defines each instance of a component in thecomponent tree. The instance data type does not actually implement themethods of a component. Instead, it serves as a holding structure for acomponent's interface data. Consequently, it merely associates itselfwith a registered component. When a script runs, the associatedcomponent executes its encapsulated code, and its behavior is dictatedby any methods invoked thereon as well as the instance's relativeposition in the component tree.

The logic node data type supports the interaction between two instances,a parent instance and a child instance. The parent instance, childinstance, and the method that defines that particular parent-childinteraction are included in the logic node data structure.

By setting the instance data types and the logic node data types ofinstance manager 206, a tree may be defined, either from scratch orbased on a previously saved script. FIG. 18 shows a flow chart for ascript loading process 1800.

Script load process 1800 begins at step 1802 when a user chooses to loada previously saved script. After the user chooses the script file theywish to load, development environment 200 sets an XML content eventhandler at block 1804. The XML handler is set with markup languageparameters for parsing the selected script file. The script file isparsed at block 1806, with component-tree section 1630 set in temporarymemory. Because the first component of the component-tree section 1630is always of the Environment type, this is converted to a logic nodedata type with its parent instance set to NULL at block 1808. At block1810, a recursive loop navigation of the tree begins where the temporarymemory examined to see if there are any children components relative tothe currently indexed location in the loop. If there is a childcomponent listed, a look-up is performed to confirm that the componentis registered and, upon confirmation, instance manager 206 establishesan instance data object for the component at block 1812. A logic nodeobject is created which invokes the component-type method as prescribedin the script file to set this new instance of a component to the treeat block 1814. Process 1800 loops back to block 1810 where the temporarymemory is examined for additional child components in the tree. If thereare no more child components listed and all components of the tree havebeen navigated, then the temporary memory is destroyed and the scriptload process concludes at block 1816 by displaying the component tree oncanvas 302 of GUI 202.

Whether a user is starting a new script or manipulating a previouslysaved script, components are added and removed from the component treeby creating new instance data objects and logic node data objects, ordestroying existing instance data objects and logic node data objects ofinstance manager 206, respectively.

A feature of the present invention is the capacity to add or delete aninstance of a component in the component tree while a script is running.Recompilation is not required. FIG. 19 shows a flow chart of a runprocess 1900 for running a script.

Process 1900 begins at block 1902 when a user chooses to run thecurrently loaded script. Proceeding to block 1904, developmentenvironment 200 allocates memory for a thread group, which is a set ofthreads that may be manipulated all at once rather than individually. Atblock 1906, development environment 200 initiates thread execution forthe collection of command methods in the component tree as managed byinstance manager 206. As noted earlier, command methods denote actionwithin the component structure. Therefore, the command methods determineinstantiation or termination of any running thread. Any subsequentcomponent actions defined by the script occur within these threads ofexecution. At block 1908, the thread group target is set to thecurrently running threads. The process for running a script ends atblock 1910, when either a user chooses to terminate the running script,or until each running thread stops by completion. If a user decides toterminate the running script, development environment 200 terminates thethread group and all running threads within the group are destroyed.

Components can be set or unset from a running script without having tostop and recompile. Development environment 200 uses a public interfacecomprising set and unset methods implemented by each component wrapper1404 for appropriately setting and unsetting that particular componentfrom a running script.

4. Deployment Manager 208

A unique and novel feature of the present invention is the one-clickdeployment process to deploy the script to an executable component-basedarchitecture. The novelty of the process is that a deployable interfaceis called by development environment 200, but the interface isimplemented by individual deployable components, using build functionsproprietary to each component, thereby establishing modularity andindependence among what may be necessarily unique deployment procedures.Deployment is dependent on the components themselves, and not ondevelopment environment 200. FIG. 20 shows a one-click deploymentprocess 2000 managed by deployment manager 208.

Process 2000 begins at block 2002, when a user actuates the build anddeploy process after selecting a component in the component tree fordeployment. Proceeding to block 2004, development environment 200verifies that the selected instance is deployable. The selectedcomponent is deployable if the associated component wrapper implements apublic deployable interface of development environment 200. In thismanner, each component 1404 is responsible for deploying itself. If theselected component is not deployable, an error is indicated to the userat block 2006 and deployment process 2000 concludes at block 2008.However, if the selected component is deployable, developmentenvironment 200 invokes the deployment method encapsulated in thecomponent wrapper at block 2010. In cascading fashion, each component isresponsible for calling the deployment method of the components at thenext lower hierarchal level in the component tree, as well as passingany parameters thereto required for deployment. Hence, a child componentdeploys differently depending on its parent component. At decision block2012, the deploying component is examined for one or more childcomponents. If the deploying component has one or more child componentsin the tree, then deployment is initiated on the child(ren) component(s)at block 2014, which includes invoking the deployment methodencapsulated in the child(ren)'s component wrapper(s). Blocks 2012 and2014 may be called recursively, until the lowermost child component inthe component tree is reached. Once it is determined that there are nolonger any children in the tree at block 2012, each component runs itsdeployment function to completion at block 2016, successively workingback up the tree to the original, selected deployable component. In thismanner, any parent component does not fully deploy until all childcomponents on a lower hierarchal level are deployed. This could easilybe achieved using a recursive method call, however there are alternativemeans as well. After all instances are deployed, deployment process 2000ends at block 2008.

Because each component is responsible for deploying itself, developmentenvironment 200 can deploy any type of component. For example, anApplication component may deploy by building and compiling a “Main”file. In contrast, a SeivletScript component may deploy by building andcompiling a servlet class. Development environment 200 can handle eithersituation, since each component wrapper implements the logic forbuilding and deploying the final product interconnecting the associatedcomponent binaries.

In one embodiment of the invention, development environment 200 may havean embedded webserver for sharing or receiving components with otherusers. The webserver is connected to a network such as a local areanetwork, or a global network such as the Internet.

In a peer-to-peer network setting, each user of development environment200 has a local repository of components comprising the componentbinaries, the associated component wrappers, and the associatedinterface definition files. A user can publish the repository to thenetwork, which allows other users to pull the components from thenetwork for use.

Each user's published repository preferably has a component registrationfile which lists the components available therein. When a user connectsdevelopment environment 200 to the network, development environment 200searches the network for published component registration files. Thesepublished component registration files are used in the same manner asthe local component registration file by development environment 200. Inthis manner, development environment 200 registers the components ofpublished repositories on the network. Information on the components iseasily shared using the interface definition file, which is preferablyin a structured markup language such as XML. A user of developmentenvironment 200 may build scripts as already described herein, havingthese additional, shared components now available.

When a script is run or deployed, development environment 200 ensuresthat all required resources are present. If any of the resources are notavailable, development environment 200 searches the network for therequired resources and, if found, pulls them from the network to thelocal repository.

In an alternative embodiment, a “logic-hub” can be employed thatincorporates a central server that hosts a published repository ofcomponents. A development environment 200 may pull the shared componentsfrom the published repository for use in building or manipulating ascript.

In still yet another alternative embodiment, a work group cancollaboratively work with a central server holding a script. The workgroup can collaboratively build and modify a script on the centralserver, posting updates thereto.

While this invention has been described in conjunction with specificembodiments thereof, it is evident that many alternatives, modificationsand variations will be apparent to those skilled in the art.Accordingly, the preferred embodiments of the invention as set forthherein, are intended to be illustrative, not limiting. Various changesmay be made without departing from the true spirit and full scope of theinvention as set forth herein and defined in the claims.

1. A computer program embodied on a computer-readable medium providing adevelopment environment for creating a component-based architecture, thecomputer program comprising: first software configured to register oneor more software components in accordance with an interface definitionfile associated with each component, each interface definition filebeing based on a structured markup language identifying one or moremethods invocable by the associated component; second softwareconfigured to generate a graphical interface so as to enable a user tobuild a component-based script in a hierarchal tree format using thecomponents, the hierarchal tree format comprising a plurality ofhierarchal levels, wherein at least one instance of a component of afirst level is configured to interact with at least one component of asecond level as defined by the one or more methods; third softwareconfigured to manage a data structure which organizes the components andthe one or more methods of the script; and, fourth software configuredto deploy the script to a component-based architecture.
 2. The computerprogram of claim 1, wherein the first software performs the steps of:parsing the interface definition file, each interface definition filecomprising an interface definition, and storing the interface definitioninto a memory module.
 3. The computer program of claim 1, wherein thefourth software deploys the script using a deployable interfaceindividually implemented by the one or more components.
 4. The computerprogram of claim 1, further comprising: fifth software configured forexchanging components over a network.
 5. The computer program of claim4, wherein the network is a global network.
 6. The computer program ofclaim 4, wherein the fifth software is a webserver.
 7. The computerprogram of claim 4, wherein the network is a peer-to-peer network.
 8. Acomputer-implemented method providing a visualization of acomponent-based architecture development environment comprising the stepof: generating a display of a component-based script in ahierarchal-tree format comprising one or more hierarchal levels, eachlevel comprising at least one component wherein a relationship betweenthe at least one component of a first hierarchal level and the at leastone component of a second hierarchal level is visually represented asbeing defined by a method.
 9. The computer-implemented method of claim8, wherein the display comprises a canvas for displaying the script, andan interacts window for displaying the one or more methods available fordefining the relationship between the components of the script.
 10. Thecomputer-implemented method of claim 9, wherein the interacts windowfurther displays one or more components that may be passed as aparameter to the one or more method selections.
 11. Thecomputer-implemented method of claim 8, wherein portions of the scriptmay be toggled between a hidden state and a revealed state.
 12. Thecomputer-implemented method of claim 8, wherein the display of thescript may be expanded or collapsed in real time enabling an unlimitednumber of intermediate positions.
 13. The computer-implemented method ofclaim 8, wherein the one or more components are displayed connected tothe method by connect-bars.
 14. A software component framework includingone or more components, each component comprising: a component binarycomprising an implementation portion of the component framework, acomponent wrapper comprising an interface portion of the componentframework enabling the component binary to interface with a developmentenvironment, and an interface definition file comprising an interfacedefinition portion of the component framework that enables the componentwrapper to register with the development environment.
 15. The softwarecomponent framework of claim 14, wherein the component binary is acompiled object class.
 16. The software component framework of claim 14,wherein the interface definition file comprises a description schema ina structured markup language.
 17. The software component framework ofclaim 16, wherein the structured markup language is extensible MarkupLanguage (XML).
 18. The software component framework of claim 14,wherein the interface definition file comprises a meta section, aninterface section, and a component-tree section.
 19. The softwarecomponent framework of claim 14, wherein the interface definition fileidentifies one or more classes of which the component wrapper is aninheriting subclass.
 20. The software component framework of claim 18,wherein the interface section comprises one or more method sections eachidentifying a method encapsulated in the component wrapper, the one ormore methods being an attachment point to the component wrapper.
 21. Thesoftware component framework of claim 20, wherein each method sectionfurther identifies an object type passed to the method at invocation.22. The software component framework of claim 14, wherein if the one ormore components is deployable, the one or more components has anindividual build method for a deployment process.
 23. The softwarecomponent framework of claim 14, wherein the one or more components isshared over a network.
 24. The software component framework of claim 20,wherein the one or more methods is of a component method-type that setsa new component to a component script.
 25. The software componentframework of claim 20, wherein the one or more methods is of a propertymethod-type that sets a value to a property defining a component. 26.The software component framework of claim 20, wherein the one or moremethods is of a command method-type that denotes action within thecomponent.
 27. The software component framework of claim 25, wherein theproperty method-type sets the value to the property from either a linkcomponent whose value is set dynamically or a link-constant componentwhose value is set statically.
 28. A computer system for providing adevelopment environment for creating a component-based architecture, thesystem comprising: a processor for registering one or more softwarecomponents in accordance with an interface definition file associatedwith each component, each interface definition file being based on astructured markup language identifying one or more methods invocable bythe associated component; a display for displaying a graphical interfaceso as to enable a user to build a component-based script in a hierarchaltree format using the components, the hierarchal tree format comprisinga plurality of hierarchal levels, wherein at least one component of afirst level is configured to interact with at least one component of asecond level as defined by the one or more methods; a memory module forholding a data structure which organizes the components and the one ormore methods of the script.
 29. The computer system of claim 28, whereinthe processor deploys the script to a component-based architecture. 30.The computer system of claim 28, wherein the processor performs thesteps of: parsing the interface definition file, each interfacedefinition file comprising an interface definition, and storing theinterface definition into the memory module.
 31. The computer system ofclaim 29, wherein the processor deploys the script using a deployableinterface individually implemented by the one or more components. 32.The computer system of claim 28, further comprising a communicationsinterface for exchanging components over a network.
 33. The computersystem of claim 32, wherein the network is a global network.
 34. Thecomputer program of claim 32, wherein the network is a peer-to-peernetwork.